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METHOD, AND APPARATUS FOR SIMULATING A SYSTEM 
USING AN OBJECT ORIENTED LANGUAGE 



BACKGROUND OF THE INVENTION 
5 Field of the Invention 

The present invention relates to a method, an apparatus, and a 
storage medium for simulating a system using an object oriented language 
suitable for the simulation of a large scale system such as an SOC (System 
On a Chip), which includes a plurality of circuit modules, by means of 
10 software. 



Description of the Related Art 

There are conventional software simulators using the HDL 
(Hardware Description Language) for designing a system. FIG. 37A shows 

15 the examples of statements of a circuit model in the HDL, and FIG. 37B is a 
schematic diagram corresponding to the statement examples of FIG. 37A. 
Data is input to or output from the circuit module described in the HDL 
through terminals. The communication between the circuit modules is made 
by connecting signal lines to the terminals. For example, as shown in FIG. 

20 37B, when a circuit module C includes circuit modules A and B, a terminal 
al of the circuit module A is connected to a terminal bl of the circuit module 
B by providing a signal line cl in the circuit module C ([l] in FIG. 37A), 
connecting the terminal al of the circuit module A to the signal line cl of the 
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circuit module C ([2]), and connecting the terminal bl of the circuit module B 
to the signal line cl of the circuit module C ([3]). Once the signal line is 
connected, one of simulation models drives the signal line, and the other 
simulation model observes the signal value, and thus the signal can be 
5 transmitted. To make the communication between the circuit modules 

accurate, the terminal of one circuit module must be accurately connected to 
the terminal of the other circuit module. 

A general design procedure for designing a system including a 
plurality of circuit modules using the software simulator such as the HDL 

10 will be explained. First, the system is divided into a plurality of circuit 
modules. At that time, considering a later step of rejoining the modules, 
rules of interface between the circuit modules are defined. The rules of 
interface describe the signal line widths and roles of the terminals of the 
circuit modules. The rules are described in a document in a natural language, 

15 or are orally reported, so that a number of designers have the rules in 
common. The circuit modules are produced according to the rules. 

After all the circuit modules are produced, the system is produced 
(described) in the HDL to combine the circuit modules so that they can 
communicate with each other. It is visually judged, or it is checked by system 

20 simulation, whether the circuit modules observe the rules. When it is 

confirmed that the result of the simulation is correct, the actual circuit is 
produced, based on the HDL statements. 

Software simulation using an HDL has been developed to certify 



3 

small scale circuits or systems. However, there are some problems in the 
application of this software simulation to SOCs such as LSIs (Large Scale 
Integrations) having a high integration degree. 

For example, when connecting two circuit modules, the functions of 
5 the terminals of both the circuit modules must be checked. The conventional 
simulation using the HDL does not automatically check the functions. 
Because the terminals can be freely named in the HDL, the names of 
terminals having specific meanings, such as CLOCK, or RESET, may differ 
between the circuit modules. Therefore, when connecting the terminals by 

10 signal lines, the meanings of the terminals of the respective circuit modules 
must be visually and manually checked according to the HDL statements or 
the other documents. Thus, when combining the circuit modules to produce 
the system, the designers must do the troublesome work to check the 
connections between the modules. 

15 To connect the circuit modules, the connections of all the terminals of 

the respective circuit modules must be described. There is the problem that, 
to change the described connections, a number of portions in the statements 
must be rewritten. Even when only a clock terminal of a circuit module 
receives an input, the connections or disconnections of all the terminals of 

20 the circuit modules must be described. That is, whenever the connections are 
changed, the detailed information regarding the circuits to be connected 
must be rewritten. It therefore requires much labor to replace a circuit 
module in the system. 
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A technique of a simulation method, which differs from the software 
simulation using the conventional HDL and which is suitable for the 
development of a system including a plurality of module, is disclosed in the 
reference "OOVHDL Object-Oriented Extensions to VHDL" (IEEE 
5 Computer, Oct., 1995, pp. 18-26). The simulation method described in the 
reference uses a new language in which the features of an object oriented 
language are incorporated into the conventional HDL, and describes the 
modules and the connections between the modules. It is described in the 
reference that the features of the object oriented language, such as "class" 
10 and "inheritance", make the statements and recycling of the modules easy. 
The reference, however, does not disclose a specific means for applying the 
simulation method, or the method for describing the modules to a large scale 
system in which a plurality of various types of circuit modules are connected. 
The reference "C++ Simulator [ClassMate] for Actualizing Prior 
15 Certification of SOC (the Institute of Electronics, Information, and 

Communication Engineers, the Technical Report, VLD98-46, 1998-09) 
discloses a method for the simulation of large scale systems using the C++ 
language which is an object oriented language. The simulation method and 
the method for describing the modules, however, do not make use of the 
20 advantages of the object oriented language. Therefore, there remains a 

problem similar to that of the HDL in the recycling of the modules and the 
connections between the modules. 
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BRIEF SUMMARY OF THE INVENTION 
It is therefore an object of the present invention to provide a method, 
an apparatus, and a storage medium for simulating a system which can 
easily and reliably describe the circuit modules and their connections and 
5 expand the system and the circuit modules, using the object oriented 
language, when simulating the system including a plurality of modules 
using software. 

In a first aspect of the present invention, the simulation method for 
simulating a system having a plurality of circuit modules using software, 

10 comprises the steps of: using an object oriented language! preparing a 
plurality of circuit base classes, which describe base circuit modules as 
classes, as a library! describing the circuit modules to be simulated as 
classes by inheriting the circuit base classes prepared as the library! and 
describing the system to be simulated by combining the circuit modules 

15 described as the classes. 

In a second aspect of the present invention, the simulation method 
further comprises the step of describing the system as a class by inheriting 
the circuit base classes prepared in the library. 

In a third aspect of the present invention, the simulation method 

20 further comprises the step of preparing a component class having the 
properties of a circuit which contains a circuit operating asynchronously 
with a clock signal, and a synchronous module class, having the properties of 
a circuit operating synchronously with the clock signal in the library, which 
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is derived from the component class. 

In a fourth aspect of the present invention, the simulation method 
further comprises the step of preparing a bus class having the properties of a 
bus, a bus master class having the properties of a bus master, a bus slave 
5 class having the properties of a bus slave, as a circuit base class described as 
a class derived from the synchronous module class, in the library. 

In a fifth aspect of the present invention, the simulation method 
further comprises the step of preparing a bus master interface class, whose 
base classes are the synchronous module class, and which has the properties 
10 of a bus master interface, and a bus slave interface class having the 

properties of a bus slave interface, as the circuit base classes in the library. 

In a sixth aspect of the present invention, the simulation method 
further comprises the step of preparing a central processing unit class, 
whose base class is the synchronous module class, and which has the 
15 properties of a central processing unit, as the circuit base class in the library. 

In a seventh aspect of the present invention, the simulation method 
further comprises the step of preparing a hierarchy class, whose base class is 
the synchronous module class, and which has the properties of a hierarchy of 
a circuit containing the bus, as the circuit base class in the library. 
20 In an eighth aspect of the present invention, the simulation method 

further comprises the step of preparing a memory class, whose base class is 
the bus slave class, and which has the properties of a memory, as the circuit 
base class in the library. 
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In a ninth aspect of the present invention, the simulation apparatus, 
using a computer, for executing the above described method. 

In a tenth aspect of the present invention, the computer-readable 
storage medium stores a computer program for executing the method. 
5 The present invention is characterized by the statements of the 

simulation model of the system. The present invention uses the object 
oriented language to describe the system. Therefore, the properties of the 
circuit modules can be prepared as the class library. A user (designer) can 
use the inheritance of the properties when describing the circuit modules. 

10 The present invention provides the following advantages: (l) it is easy to 
replace the circuit module, and the connections between the circuit modules 
are automatically checked, (2) the configuration for displaying the 
information is commonly used, (3) the configuration for controlling the 
simulation is commonly used, and (4) it is automatically checked whether 

15 the statements of the circuit interfaces are sufficient. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a diagram for explaining the C++ language used in the 
embodiment of the present invention. 
20 FIG. 2 is a block diagram showing the main configuration of the 

simulation method (apparatus) of the present invention. 

FIGs. 3A and 3B are diagrams for explaining the system statements 
shown in FIG. 2. FIG. 2A shows the examples of the statements in the C++ 
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language, and FIG. 3B is a schematic diagram corresponding to the 
examples of the statements of FIG. 3A. 

FIG. 4 is a list of circuit base classes used in the embodiment of the 
present invention. 

FIG. 5 is a diagram showing the hierarchic relationships between the 
circuit base classes in the embodiment of the present invention. 

FIG. 6 is a diagram showing an example of actual circuit classes 
created from the base classes which are the circuit base classes of FIG. 4. 

FIG, 7 is a block diagram showing the simulation method (or 
apparatus) of the present invention. 

FIG. 8 is a block diagram showing an example of a circuit system for 
explaining the system statements of the embodiment of the present 
invention. 

FIG. 9 is a diagram showing the system statements of the circuit 
system shown in FIG. 8 according to the embodiment of the present 
invention. FIGs. 9 to 13 show a series of the system statements. 

FIG. 10 is a diagram showing the system statements continued from 

FIG. 9. 

FIG. 11 is a diagram showing the system statements continued from 
FIG. 10. 

FIG. 12 is a diagram showing the system statements continued from 
FIG. 11. 

FIG. 13 is a diagram showing the system statements continued from 



FIG. 12. 

FIG. 14 is a diagram showing an example of a declaration statement 
of the CmComponent class shown in FIG. 4. 

FIG. 15 is a diagram showing an example of a declaration statement 
of the CmSyncModule class shown in FIG. 4. 

FIG. 16 is a diagram showing the example of a declaration statement 
of the CmBusMaster class shown in FIG. 4. 

FIG. 17 is a diagram showing the example of a declaration statement 
of the CmBusSlave class shown in FIG. 4. 

FIG. 18 is a diagram showing an example of a declaration statement 
of the CmBusMstlntf class shown in FIG. 4. FIGs. 18 and 19 show a series of 
the statements. 

FIG. 19 is a diagram showing an example of the statement continued 
from FIG. 18. 

FIG. 20 is a diagram showing an example of a declaration statement 
of the CmBusSlvIntf class shown in FIG. 4. FIGs. 20 and 21 show a series of 
the statements. 

FIG. 21 is a diagram showing an example of the statement continued 
from FIG. 20. 

FIG. 22 is a diagram showing an example of a declaration statement 
of the CmBusSystem class shown in FIG. 4. 

FIG. 23 is a diagram showing an example of a declaration statement 
of the CmHier class shown in FIG. 4. 
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FIG. 24 is a block diagram showing the configuration of the system 
for explaining the simulation of the data transfer through the bus in an 
embodiment of the present invention. 

FIG. 25 is a diagram showing an example of data to be transferred by 
5 the system shown in FIG. 24. 

FIG. 26 is a timing chart showing the timings of the operations for 
explaining the simulation of the data transfer through the bus by the system 
of FIG. 24 according to an embodiment of the present invention. 

FIG. 27 is a diagram for explaining the operations in a manner of a 
10 time series within timel of FIG. 26. 

FIG. 28 is a diagram for explaining the operations in a manner of a 
time series within time2 of FIG. 26. 

FIG. 29 is a diagram for explaining the operations in a manner of a 
time series within time3 of FIG. 26. 
15 FIG. 30 is a diagram for explaining the operations in a manner of a 

time series within time4 of FIG. 26. 

FIGs. 31A and 3 IB are diagrams for explaining a method for creating 
a new class according to the embodiment of the present invention. FIG. 31A 
shows the examples of declaration statements of the class, and FIG. 31B is a 
20 schematic diagram corresponding to FIG. 31A. 

FIGs. 32A and 32B are diagrams showing the examples of system 
statements using the class ClassX shown in FIG. 31. FIG. 32A shows the 
examples of system statements, and FIG. 32B is a schematic diagram 
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corresponding to FIG. 32A. 

FIGs. 33A and 33B are diagrams showing other examples of system 
statements using the class ClassX shown in FIG. 31. FIG. 33A shows the 
examples of system statements, and FIG. 33B is a schematic diagram 
5 corresponding to FIG. 33A. 

FIGs. 34A and 34B are diagrams for explaining another method for 
creating a new class according to the embodiment of the present invention. 
FIG. 34A shows the examples of declaration statements of the class, and FIG. 
34B is a schematic diagram corresponding to FIG. 31A. 
10 FIGs. 35A and 35B are diagrams showing other examples of system 

statements using the class ClassY shown in FIG. 34. FIG. 35A shows 
examples of system statements, and FIG. 35B is a schematic diagram 
corresponding to FIG. 35A. 

FIGs. 36A and 36B are diagrams showing examples of system 
15 statements. FIG. 36A shows examples of system statements, and FIG. 36B is 
a schematic diagram corresponding to FIG. 36A. 

FIGs. 37A and 37B are diagrams for explaining the example of a 
circuit system in the conventional HDL. FIG. 37A shows examples of system 
statements, and FIG. 37B is a schematic diagram corresponding to FIG. 37A. 

20 

DETAILED DESCRIPTION OF THE INVENTION 
The embodiment of the simulation method of the present invention 
will be explained with reference to the figures. In the embodiment, a 



12 

simulation model is described in the C++ language. The C++ language and 
the terms used in the description will be defined in the following. 

[C++ Language] 

5 The C++ is a programming language, and is classified as an object 

oriented language. The terms used in the C++ are class, member function 
(method), object, inheritance, base class, derived class, override (overload), 
pure virtual function, etc. The class represents a property. The property is 
described by a member function. The member function defines the operation 

10 of the class. The member function is sometimes termed a method. In general, 
when the ClassX is permitted to perform the operation of a member function 
Functionl, it is called "the ClassX has Functionl". The object is an entity 
which is embodied from a class. When the class ClassX is embodied to obtain 
the object ObjectX, it is said that "the ObjectX is of the ClassX". The object 

15 has properties which are defined in the class. For example, in the example 
described in the C++ language in FIG. 1, because ClassA has member 
functions Functionl and Function2 ([l]), ObjectAhas Functionl and 
Function2 ([2]). 

The inheritance means that the property of a class is inherited by 
20 another class. Specifically, a member function defined in one class is also 
defined in another class which inherits the class. For example, when 
producing ClassB inheriting ClassA ([3]), ClassA has the member function 
Functionl, and therefore ClassB tacitly has Functionl even when ClassB 
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does not define Functionl ([4]). 

The base class is a class inherited by another class. In the above 
example, ClassAis the base class of ClassB ([3]). The derived class is a class 
which inherits another class. In the above example, ClassB is the class 
5 derived from ClassA. To define the derived class, as shown in the statement 
denoted by [3] , the name of the derived class (ClassB) is described after a 
reserved word "class", and subsequently "^public ClassA" (ClassAis the name 
of the base class) is described. The "public" is a reserved word which 
designates the manner of derivation (the way of accessing the member of the 

10 base class (public derivation). The object of the derived class can be handled 
as the object of the base class. For example, ObjectB of ClassB can be 
handled as the object of ClassA ([5]). 

"Override" means re-defining the operation of the member function 
in the derived class, which has been defined in the base class. For example, 

15 in FIG.l, although ClassA defines the function of the member function 
Function2 (the portion [6], whose detailed description is omitted), this 
function is not desired in the derived class ClassB. Accordingly, ClassB 
redefines the member function Function2 to change the operation of 
Function2 ([7]). This is termed overriding Function2 in ClassB. When ClassB 

20 overrides Function2, the operation of Function2 in ClassB differs from that 
of Function2 in ClassA. 

A member function whose operation is not defined in the class is 
termed a pure virtual function ([8], which is described by the expression 
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M [function]=0"). When producing the object of the class having the pure 
virtual function, the compiling causes an error ([9], where, in FIG. 1, "//" 
indicates comments in the C++ language). The virtual pure function is to be 
overridden in the derived class which inherits and uses the class with the 
5 virtual pure function ([10]). 

[Premise] 

The premise for performing the simulation, that is, using the 
embodiment will be explained. In general, to construct the system, the 

10 system is divided into blocks according to the functions. The blocks are 

termed circuit modules. The communication between the circuit modules is 
determined. Then, the circuit modules are separately designed. After the 
design of all the circuit modules is completed, the circuit modules are 
assembled into a single system. The system is operated by the 

15 communication between the circuit modules. The procedure for the 

simulation of the system is described below (with reference to FIG. 2). 

1. The system which is the simulation target is described in the C++ 
language. 

(A) The classes of the circuit modules are declared ([l] in FIG. 2). In 
20 the example of FIG. 2, a CPU class 101, a bus master interface class 102, 

and a bus class 103 are produced as user created classes. 

(B) The simulation model (system statement 104) of the entire 
system is produced ([2]). The objects of the circuit classes included in the 
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system are produced ([3]). Next, the objects are connected, and the 
communication between the circuit objects is described. The simulation 
model of the entire system is thus described ([4]). The connection between 
the circuit objects is achieved by giving the pointer of a circuit object A to 
5 another circuit object B. The communication between the circuit objects is 
achieved by executing the function of the circuit object A from the circuit 
object B (see FIG. 3). FIG. 3A shows the examples of the statements in the 
C++ language in which ObjectB receives data indicated by an argument i 
from ObjectA (GetData), and FIG. 3B is schematic diagram thereof. 

10 (C) Next, an information display section of the circuit is incorporated. 

In the prior certifications with simulations, it was necessary to know how 
the CPU and the bus operate, for example, to know the portion of software 
the CPU is executing, the variables of the software operating in the CPU, 
the share of the bus, a master which is using the bus, or the like. The 

15 statement of the process for displaying those information is added to the 

system statement. In FIG. 2, the statement for displaying the information of 
the bus prepared in advance in a library, and the statement for displaying 
the information of the bus may be modified if necessary, and are 
incorporated at appropriate positions in the system statement 104 as a CPU 

20 information display section 105 and as a bus information display section 106, 
respectively. 

2. A simulation controller is incorporated. 

When executing the simulation, the system can be reset or operated, 
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depending on an instruction from a user. Therefore, a section for controlling 
the system, depending on the user instructions, is added to the system 
statement 104 to complete a simulator source 108. 

3. The simulation mode (simulator source 108), described in item 2, 
5 is compiled by a C++ compiler 109, to thereby obtain the execution type of 

the simulator (simulator 110). 

4. The simulation is executed by the simulator 110. 

When the simulation certifies that the system operation is normal, 
the actual circuit is produced based on the statement in the C++ language. 

10 

[Schematic Configuration of the Embodiment of the Invention] 

The classes used in the embodiment will be explained. The 
embodiment prepares the classes, shown in FIG. 4, as a class library. As 
shown in FIG. 4, the embodiment defines a class CmComponent (component 

15 class) with the properties common to the entire circuit, a class 

CmSyncModule (synchronous module class) with the property of the circuit 
operating synchronously with a clock, a class CmBusMaster (bus master 
class) with the property of the main section of a bus master, a class 
CmBusSlave (bus slave class) with the property of the main section of a bus 

20 slave, a class CmBusMstlntf (bus master interface class) with the property 
of bus master interface, a class CmBusSlvIntf (bus slave interface class) with 
the property of bus slave interface, a class CmBusSystem (bus class) with 
the property of bus, a class CmCpu (CPU class) with the property of a CPU, 
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a class CmMemory (memory class) with the property of a memory, and a 
class CmHier (hierarchy class) with the property of a hierarchy of the circuit 
containing the bus. 

In the present invention, the classes, prepared as the library, are 
5 termed a circuit base class. The classes have the relationship of inheritance 
as shown in FIG. 5. In FIG. 5, the class CmSyncModule 202 inherits the 
class CmComponent 201. The other classes CmBusMaster 203, CmBusSlave 
204, CmBusMstlntf 205, CmBusSlvIntf 206, CmBusSystem 207, and 
CmHier 208 inherit the class CmSyncModule 202. FIG. 5 shows, in addition 

10 to the relationship of inheritance between the classes, the list of main 

member functions of the classes. The details of the member functions will be 
discussed below. Although not shown in FIG. 5, the class CmCpu (CPU class) 
inherits the class CmBusMaster 203, and the class CmMemory (memory 
class) inherits the class CmBusSlave 204. 

15 When dividing the system into the circuit modules, the roles of the 

respective circuit modules must be decided. Therefore, when describing 
circuit classes corresponding to the circuit modules, the circuit modules are 
defined as classes derived from the circuit base classes (as actual circuit 
classes, or user created classes) by selecting and inheriting the circuit base 

20 classes corresponding to the roles from the class library. The circuit classes 
for performing desired operations are realized by overriding the functions. 

The examples of the actual circuit classes are shown in FIG. 6. In the 
classes used to create the model of a PCI bus (Peripheral Component 
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Interconnect), the examples are a class CmPciBusMstlntf derived from the 
circuit base class CmBusMstlntf, a class CmPciBusSlvIntf derived from the 
circuit base class CmBusSlvIntf, a class CmPciBusSystem derived from the 
circuit base class CmBusSystem, and a class CmV850 derived from the 
5 circuit base class CmCpu used to create the mode of V850 (trademark) CPU. 
After the circuit classes in the system are created, the system is 
described as one class. The class of the system contains the objects of the 
circuit classes created in the above step. Further, the circuit information 
display section is incorporated in the class of the system. The class of the 
10 system selects and inherits the circuit base classes, which are suitable for 
the properties of the system, from the class library. 

The method of the simulation of the present invention is described in 
the following. An example is shown in FIG. 7. 

1. The system which is the target of the simulation is described in 
15 the C++ language. 

(A') The classes of the circuit modules are declared (created) by 
inheriting the circuit base classes suitable for the respective modules from 
the class library 300 in which a plurality of circuit base classes have been 
prepared in advance. In the example shown in FIG. 7, a user created CPU 
20 class 101 is declared by inheriting the CPU circuit base class (CmCpu) 301, a 
user created bus master interface class 102 is declared by inheriting the bus 
master interface circuit base class (CmBusMstlntf) 302, and a user created 
bus class 103 is declared by inheriting the bus circuit base class 
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(CmBusSystem) 303. 

(B') The class of the system is created by inheriting suitable circuit 
base class from the class library 300. In the example of FIG. 7, the class is 
created by inheriting the synchronous circuit circuit base class 
5 (CmSyncModule) 304 ([2] in FIG. 7). 

(C) Next, the circuit information display section (a CPU display 
section 105, and a bus information display section 106) are incorporated. 

The steps (AO, (BO, and (CO are basically similar to the steps (A), (B) ( 
and (C) described in the premise with reference to FIG. 2, except that the 
10 classes of the circuit modules and of the system which includes the circuit 

modules are created by inheriting the circuit base classes defined in the class 
library 300. In FIG. 7, the reference numerals are employed to denote like 
parts in FIG. 2. 

2. Next, a simulation controller 107 is incorporated to create a 
15 simulator source 108. 

3. The statement of the item 2 is compiled by the C++ compiler 109 
to obtain the execution type of the simulator 110. 

4. The simulation is performed by executing the simulator. 

In the embodiment, since the system inherits the circuit base class, 
20 the system has the properties of the circuit modules. Hence, the system can 
be used as a circuit module which is to be included in another system. That 
is, the systems can be described hierarchically. When the system is described 
hierarchically, the effect of the present invention can be achieved. 



20 



[Details of Circuit Base Class] 

Next, the circuit base class shown in FIG. 4 will be explained in 

detail. 

5 (l) The CmComponent class has the following functions, and is used 

to describe a combination circuit having no clock. 

The CmComponent class has a Reset function. The function is used 
for asynchronous resetting. 

The CmComponent class has a GetPinValue function. The function is 
10 executed by a circuit X when the circuit X reads the value of a signal at a 
terminal of a circuit Y. 

The CmComponent class has a SetPinValue function. The function is 
executed by the circuit X when the circuit X applies a signal to the terminal 
of the circuit Y. 

15 A Reset function is a pure virtual function. Therefore, the process of 

the function must be defined in the class which inherits CmComponent. 
Further, the embodiment provides, in addition to the communication 
between the circuits through the terminals, the communication through the 
bus. The communication through the bus is simulated at a high speed by the 

20 CmBusMaster class, and the CmBusSlave class. Therefore, the 
communication which does not use the bus is described with the 
GetPinValue function and the SetPinValue function. 

(2) The CmSyncModule class has the following functions, and is used 
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to describe a sequence circuit which has a clock. 

The CmSyncModule class has the Reset function, the GetPinValue 
function, and the SetPinValue function. The meanings of the functions are 
the same as those in the CmComponent class. 
5 The CmSyncModule class has a OneStep function. The function is 

used to perform a one step operation of the circuit. The OneStep function is a 
pure virtual function. Therefore, the process of this function must be defined 
in the class which inherits CmSyncModule. 

(3) The CmBusMaster class has the following functions, and is used 
10 to describe the main section of the bus master. The bus master is used to 
describe the circuit module which actively drives the bus. The bus master 
interface, which is referred to in the following description, is a circuit module 
between the bus and the bus master to absorb the differences between the 
buses. 

15 The CmBusMaster class has the Reset function, the GetPinValue 

function, the SetPinValue function, and the OneStep function. The meanings 
of the functions are the same as those in the CmSyncModule class. 

The CmBusMaster class has a ReadBusMaster function. The 
function reads a value from an object to the bus. 
20 The CmBusMaster class has a WriteBusMaster function. The 

function writes a value from the bus into an object. 

The CmBusMaster class has a ConnectBusMstlntf function. The 
function is used to connect the bus master interface. 
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The ReadBusMaster function, and the WriteBusMaster function are 
pure virtual functions. Therefore, the processes of those functions must be 
defined in the class which inherits CmBusMaster. 

(4) The CmBusSlave class has the following functions, and is used to 
5 describe the main section of the bus slave. The bus slave is a circuit module 

which passively receives data from the bus. In the following description, the 
bus slave interface is a circuit module between the bus and the bus slave to 
absorb the differences between the buses. 

The CmBusSlave class has the Reset function, the GetPinValue 
10 function, the SetPinValue function, and the OneStep function. The meanings 
of the functions are the same as those in the CmSyncModule class. 

The CmBusSlave class has a ReadBusSlave function. The function 
reads a value from the object to the bus. 

The CmBusSlave class has a WriteBusSlave function. The function 
15 writes a value from the bus to the object. 

The CmBusSlave class has a ConnectBusSlvIntf function. The 
function is used to connect the bus slave interface. 

The ReadBusSlave function, and the WriteBusSlave function are 
pure virtual functions. Therefore, the processes of those functions must be 
20 defined in the class which inherits CmBusSlave. 

(5) The CmBusMstlntf class has the following functions, and is used 
to create the bus master interface. The bus master interface is a circuit 
module which absorbs the differences between the buses when actively 
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driving the bus. 

The CmBusMstlntf class has the Reset function, the GetPinValue 
function, the SetPinValue function, and the OneStep function. The meanings 
of the functions are the same as those in the CmSyncModule class. 
5 The CmBusMstlntf class has an IsBusReq function. The function 

returns whether the bus master interface requests the use of the bus. 

The CmBusMstlntf class has an AssertBusGnt function. The 
function notifies the bus master interface of the permission of the use of the 
bus from an external circuit (which is normally an arbiter). 
10 The CmBusMstlntf class has a DisassertBusGnt function. The 

function notifies the bus master interface of the prohibition of the use of the 
bus from the external circuit (which is normally an arbiter (or arbitor)). 

The CmBusMstlntf class has an AppendWriteData function, a 
Start Write function, an IsWriteEnd function, an AppendReadAd dress 
15 function, a StartRead function, an IsReadEnd function, and a GetReadData 
function. These functions are used to control the class CmBusSystem object 
from the class CmBusMaster object. 

The AppendWriteData function writes an address of the bus slave to 
which the data is to be written, the data to be written, and the number of 
20 bytes of the data to be written, in a predetermined variable area (buffer) in 
the class. The Start Write function starts the writing operation of the data to 
the bus. The IsWriteEnd function returns the result indicating whether the 
writing operation of the data to the bus is completed. The 
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AppendReadAddress function writes the address of the bus slave from which 
the data is to be read, and the number of bytes of the data to be read, into 
the buffer. The StartRead function starts the reading operation of the data 
from the bus. The IsReadEnd function returns the result indicating whether 
5 the reading operation of the data from the bus is completed. The 

GetReadData function draws the data, which has been read from the bus 
slave to the buffer, from the buffer. 

(6) The CmBusSlvIntf class has the following functions, and is used 
to describe a circuit module for absorbing the differences between the buses 
10 when passively receiving the data from the bus. 

The CmBusSlvIntf class has the Reset function, the GetPinValue 
function, the SetPinValue function, and the OneStep function. The meanings 
of the functions are the same as those in the CmSyncModule class. 

The CmBusSlvIntf class has an IsBusReq function. The function 
15 returns whether the bus slave interface requests the use of the bus. 

The CmBusSlvIntf class has an AssertBusGnt function. The function 
notifies the bus slave interface of the permission of the bus from an external 
circuit (which is normally an arbiter). 

The CmBusSlvIntf class has a DisassertBusGnt function. The 
20 function notifies the bus slave interface of the prohibition of the use of the 
bus from the external circuit (which is normally an arbiter). 

The CmBusSlvIntf class has an AppendWriteData function, a 
Start Write function, an IsWriteEnd function, an AppendReadAddress 
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function, a StartRead function, an IsReadEnd function, and a GetReadData 
function. The functions are used when the derived class from the 
CmBusSystem class writes or reads a value to or from the CmBusSlvIntf 
class. The base functions of those functions are similar to those in the 
5 CmBusMstlntf class, except that the target to be written or read is different. 

(7) The CmBusSystem class has the following functions. The 
functions are used to describe a circuit module for transferring the data from 
the master to the slave. 

The CmBusSystem class has the Reset function, the GetPinValue 
10 function, the SetPin Value function, and the OneStep function. The meanings 
of the functions are the same as those in the CmSyncModule class. 

The CmBusSystem class has a ConnectBusMstlntf function. The 
function connects the class, derived from the CmBusMstlntf class, to this 
object. 

15 The CmBusSystem class has a ConnectBusSlvIntf function. The 

function connects the class, derived from the CmBusSlvIntf class, to this 
object. 

The CmBusSystem class has a SetUserReadMap function. The 
function is used to designate a bus read map of the bus. The bus read map is 
20 an address map used to read a value from a circuit module through the bus. 
The bus read map is described as a UserReadMap function in a CmHier 
class. 

The CmBusSystem class has a SetUserWriteMap function. The 
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function is used to designate a bus write map of the bus. The bus write map 
is an address map which is used to write a value into the circuit module 
through the bus. The bus write map is described as a UserWriteMap 
function in the CmHier class. 
5 The CmBusSystem class has a SetUserArbitor function. The function 

is used to designate an arbiter (or, arbitor) of the bus. The arbiter arbitrates 
the use right of the bus. This circuit is described as a UserArbitor function in 
the CmHier class. 

The CmBusSystem class has a ReadMap function. The function 
10 reads the information from the circuit module through the bus. 

The CmBusSystem class has a WriteMap function. The function 
writes information into the circuit module through the bus. 

(8) The CmCpu class inherits the CmBusMaster class, has the 
following functions, and is used to describe the CPU. 
15 The CmCpu class has the Reset function, the GetPinValue function, 

the SetPin Value function, the OneStep function, and the ConnectBusMstlntf 
function. The meanings of the functions are the same as those in the 
CmSyncModule class. 

The CmCpu class has a ConnectBusMstlntf function. The function is 
20 used to connect the bus master interface. 

The CmCpu class has a GetPc function. The function returns a 
present value of a program counter. 

The CmCpu class has a GetReg function. The function returns the 
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value of a designated register. 

The CmCpu class has a SetReg function. The function returns the 
value of a designated register. 

The CmCpu class has a GetData function. The function returns the 
5 data stored in a designated address. 

The CmCpu class has a SetData function. The function overwrites 
the data into a designated address. 

As described above, the circuit base class CmCpu, which provides the 
model of the CPU, has the functions defined in the CmBusMaster class by 
10 inheriting the circuit base class CmBusMaster which provides the model of 
the bus master. In addition, the circuit base class CmCpu can display the 
information from the registers and the program counters on the CPU 
information display section when executing the program, using the GetPc 
function, the GetReg function, the SetReg function, the GetData function, 
15 and the SetData function. 

(9) The CmMemory class inherits the CmBusSlave class, has the 
following functions, and is used to describe the memory. 

The CmMemory class has the Reset function, the GetPinValue 
function, the SetPinValue function, the OneStep function, and the 
20 ConnectBusSlvIntf function. The meanings of the functions are the same as 
those in the CmBusSlave class. 

The CmMemory class has a GetData function. The function returns 
the data stored in a designated address. 
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The CmMemory class has a SetData function. The function 
overwrites the data in a designated address. 

(10) The CmHier class inherits the CmSyncModule class, has the 
following functions, and is used to describe the system which includes the 
5 bus. 

The CmHier class has the Reset function, the GetPinValue function, 
the SetPinValue function, and the OneStep function. The meanings of the 
functions are the same as those in the CmBusSlave class. 

The CmHier class has a UserReadMap function. The function is used 
10 to describe the bus read map of the bus included in the system. The 

described bus read map is registered in the bus by the SetUserReadMap 
function in the CmBusSystem class. 

The CmHier class has a UserWriteMap function. The function is 
used to describe the bus write map of the bus included in the system. The 
15 described bus read map is registered in the bus by the SetUserWriteMap 
function in the CmBusSystem class. 

The CmHier class has a UserArbitor function. The function is used to 
describe the arbiter of the bus included in the system. The described arbiter 
is registered in the bus by the SetUserArbitor function in the CmBusSystem 
20 class. 

Next, the examples of the statements of the system for transferring 
the data through the bus, according to the present invention, will be 
explained. Before the explanation of the examples of the statements, the 
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address map and the arbiter, mentioned above, will be explained. 

The address map is a table indicating the allocation of the circuits to 
the addresses. The arbiter is a circuit which gives the use right to one of the 
bus masters requesting the use of the bus. These are well known in general. 
5 First, the address map will be explained. 

A number of circuits are connected to the bus. When the data is 
simply sent to the bus, it cannot be known which circuit is to receive the 
data as an instruction. Therefore, an address is used to designate one of the 
circuits. Data and an address are always transferred as a pair through the 
10 bus. Further, the circuit which receives the data depends on the 

predetermined address. The relationships between the addresses and the 
circuits are defined in the address map. 

The transfer of a pair of the data and the address through the bus 
corresponds to the statement of giving the pair of the data and the address to 
15 the UserReadMap function and the UserWriteMap function of the CmHier 
class. The address map of the embodiment corresponds to the statement of 
determining the circuit corresponding to the address given to the 
UserReadMap function and the UserWriteMap function, and of sending the 
data to the circuit. 

20 The arbiter is needed when two or more bus masters are connected to 

the bus. The bus simply sends a signal through a signal line. Therefore, 
when two or more bus masters simultaneously send the signals through the 
bus, two signals collides in one signal line. Thus, a correct value cannot be 
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transferred to the target circuit module. To avoid this, the arbiter is used. In 
general, when using the arbiter, the bus master must request the use of the 
bus to the arbiter. The arbiter, which has received the request from the bus 
masters, permits one of the bus masters to use the bus. The bus master 
5 cannot use the bus until the bus master receives the permission of the use of 
the bus. 

In the embodiment of the present invention, the bus master is 
divided into the bus master and the bus maser interface. The 
permission/prohibition of the use of the bus is sent from the arbiter to the 

10 bus master interface. 

The example of the communication of the data through the bus will 
be explained with reference to FIGs. 8 to 13. FIG. 8 is a block diagram 
showing the construction of the system ABC used in the example. FIGs. 9 to 
13 show a series of lists of the statements of the system in the C++ language. 

15 FIGs. 9 to 13 continue in the order of drawing numbers. 

As shown in FIG. 8, the system ABC comprises two CPUs (a CPU 1 
(402), and a CPU 2 (403)), and a timer 1 (404), and a counter 1 (405), which 
are connected through a PCI bus 401. The respective CPU 1 (402), the CPU 
2 (403), the timer 1 (404), and the counter 1 (405) have interfaces 402a, 403a, 

20 404a, and 405a, each of which includes an interface with the PCI bus 401. 

Assuming that a plurality of circuits, not shown, are connected to the system 
ABC of FIG. 8, the positions of the statements of those circuits will be 
additionally explained in the following explanation of the statement example 
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of the system. 

In the system statements shown in FIG. 9, it is first declared that an 
object ABC, corresponding to the system ABC, inherits the CmHier class ([l] 
in FIG. 9). Next, the PCI bus, corresponding to the PCI bus 401 in FIG. 8, is 
5 created as a user created class (actual circuit class) CmPciBusSystem (whose 
circuit base class is the CmBusSystem class) in the system ABC ([2] in FIG. 
9). As the CPU 1 (402) and the CPU 2 (403) in FIG. 8, two CPUs are created 
by the CmCpu class of the objects Cpul and Cpu2 in the system ABC ([3] in 
FIG. 9). Since the objects Cpul and Cpu2 are the bus masters, the bus 

10 master interface objects CpulBusMstlntf and Cpu2BusMstIntf for 

connecting the objects Cpul and Cpu2 to the bus are created ([4] in FIG. 9, 
corresponding to the interfaces 402a and 403a in FIG. 8). The bus master 
interfaces CpulBusMstlntf and Cpu2BusMstIntf are created by the user 
created class CmPciBusMstlntf (whose circuit base class is the 

15 CmBusMstlntf class). 

Next, a circuit Timerl corresponding to the timer 1 (404) is created 
in the system ABC ([5] in FIG. 9). Since the object Timerl is the bus slave, a 
bus slave interface (corresponding to the interface 404a in FIG. 8) for 
connecting the object Timerl to the bus is created in the system ABC ([6] in 

20 FIG. 9). Next, a circuit Counter 1 corresponding to the counter 1 (405) is 

created in the system ABC ([7] in FIG. 9). Since the object Counter 1 is a bus 
slave, a bus slave interface (corresponding to the interface 405a in FIG. 8) 
for connecting the object Counterl to the bus is created in the system ABC. 
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The object Timerl is created, based on the user created class CmTimerl, and 
the object Counterl is created, based on the user created class Cmcounterl. 
The user created classes CmTimerl and CmCounterl are derived from the 
CmBusSlave class. The bus slave interface objects TimerlBusSlvIntf and 
5 CounterlBusSlvIntf are declared, based on the derived class 
CmPciBusSlvIntf from the CmBusSlvIntf class. 

The other module is described at the position [9] in FIG. 9. 
Next, the UserBusReadMap function will be described ([1] in FIG. 
10). The UserBusReadMap function describes the bus read map. The return 

10 value is a structure RDATA. RDATA.Status is 0 on success, and 1 on failure. 
Data returns the read value when the reading is successful. ULONG 
indicates a signal value of 32 bits. The UserBusReadMap decides the circuit 
from which the value is read, based on the address, and executes the reading 
function of the bus slave interface of the circuit. First, a variable v having a 

15 return value is defined as the structure RDATA ([2] in FIG. 10). 

Next, a discriminant for reading a value from the circuit (object) 
Timerl from addresses 100 to 200 is described ([3] in FIG. 10). When the 
discriminant is true, the AppendReadAdress function is executed for the 
object Time rBusSlvIntf with arguments of 0, address- 100, and byte_eount, in 

20 order to designate the address to be read, and the number of bytes ([4] in 
FIG. 10). Next, the StartRead function is executed for the object 
TimerlBusSlvIntf, to read the value ([5] in FIG. 10). It is then checked 
whether the reading has been successful ([6] in FIG. 10). When the reading 
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is successful, v.status is set to 0 ([7] in FIG. 10), and the GetReadData 
function is executed for the object Timer lBusSlvIntf, to read the read value 
and to set v.Data to the read value ([8] in FIG. 10). When the reading fails, 
v.Status is set to 1, and the process returns ([9] in FIG. 10). When executing 
the AppendReadAddress function, the StartRead function, the IsReadEnd 
function, and the GetReadData function, the first argument is set to 0, in 
order to report that these functions are executed by the normal transfer 
method. The first argument discriminates between a transfer method (Split 
transfer) switching the master and the slave, and the normal transfer 
method. 

A statement similar to that of the circuit Timer 1 is made for the 
circuit Counterl with the read addresses 200 to 300 ([10], and [11] in FIG. 
10). Further, similar statements are made for the other circuits ([12] in FIG. 
10). 

The bus write map is described by the UserBusWriteMap function 
([1] in FIG. 11). The return value is int (integer). The return value is 0 on 
success, and 1 on failure in the writing operation. The arguments address 
and data are signal values of ULONG (32 bits). 

The circuit into which the values are to be written is determined, and 
the writing function of the bus slave interface of the determined circuit is 
executed ([2] in FIG. 11). The values are written into the addresses 100 to 
200 of the circuit Timerl ([3] in FIG. 11). The AppendWriteData function is 
executed for the object Timer lBusSlvIntf with the arguments 0, 
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(address- 100), data, and byte_count, to designate the data to be written ([4] 
in FIG. 11). Then, the Start Write function is executed to write the value ([5] 
in FIG. 11). The IsWriteEnd function is executed for the circuit Tinier 1 to 
check whether the writing has been successful ([6] in FIG. 11). When the 
5 writing has been successful, the return value is 0. When the writing has 

failed, the return value is 1. When executing the AppendWriteData function, 
the Start Write function, and the IsWriteEnd function, the first argument is 
set to 0 in a similar manner to the execution of the AppendReadAdress 
function, to report that those functions are executed by the normal transfer 
10 method. 

The circuit Counterl will be explained. From addresses 250 to 350, 
the circuit Counterl is stated in a manner similar to the circuit Timerl ([9], 
[103 in FIG. 11). The other circuits are stated in a similar way ([11] in FIG. 
11). 

15 Next, the operation of the arbiter in the UserArbitor function is 

described ([l] in FIG. 12). The return value of the UserArbitor function is 
void. The permission of the use of the bus is directly given to the bus master 
interface. The IsBusReq function is executed for the objects CpulBusMstlntf 
and Cpu2BusMstIntf, to directly draw the request, to use the bus, from the 

20 bus master interfaces ([2] in FIG. 12). The request from the object Cpul is 
preferred to that from the object Cpu2, and the preference of the requests is 
checked ([3] in FIG. 12). When the Cpul requests to use the bus, the Cpul 
can use the bus even if the Cpu2 requests to use the bus. That is, the 
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AssertBusGnt function is executed for the object CpulBusMstlntf, and the 
DiassertBusGnt function is executed for the object Cpu2BusMstIntf, to allow 
the Cpul to use the bus and to reject the use of the bus by Cpu2 ([4] in FIG. 
12). 

5 When the object Cpul does not use the bus, and when the object 

Cpu2 is to use the bus ([5] in FIG. 12), the Cpul is prohibited from using the 
bus, and the Cpu2 is allowed to use the bus ([6] in FIG. 12). When neither of 
the objects sends the request, both the objects are prohibited from using the 
bus ([7] in FIG. 12). 

10 Next, the operation and connection of the system ABC is described in 

the function ABC(void) ([1] in FIG. 13). The function ABC(void) is a function 
(constructor: the function whose name is the same as that of the class) called 
to create the object of the system ABC. The circuits and the bus interfaces 
are connected by the ConnectBusMstlntf function, or the ConnectBusSlvIntf 

15 function, and the bus interfaces and the PCI bus are connected by the 

ConnectBusMstlntf function ([2] in FIG. 13). At that time, the addresses of 
the bus interface objects of the respective circuits are used as the arguments, 
to thereby connect the PCI bus to the respective circuits. The other circuits 
are described in the same manner ([3] in FIG. 13). 

20 The SetUserReadMap function and the SetUserWriteMap function 

designate the address map for the object PciBusSystem ([4] in FIG. 13). By 
the execution of the functions, the address map is registered in the object 
PciBusSystem. Thus, the PciBusSystem can use the address map. 
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Next, the operation of the system ABC in one unit time is described 
by the OneStep function ([5] in FIG. 13). The system ABC is operated by the 
arbitrary behaviors of the components. Accordingly, in the level of the system 
ABC, the respective components in the system are simply operated in one 
5 unit time ([6] in FIG. 13 (comments)). The OneStep function is executed for 
the PCI bus PciBusSystem ([7] in FIG. 12). Although the bus does not 
require the clock because the bus is a signal line, the embodiment gives the 
clock to the bus in order to extract data synchronously with the clock in a 
debugging function. Next, the OneStep function is executed for the objects 

10 CpulBusMstlntf, Cpu2BusMstIntf, TimerlBusSlvIntf, Counter lBusSlvIntf, 
Cpul, Cpu2, Timerl, and Counterl, to operate them in one unit time ([8] in 
FIG. 12). In a similar way, the OneStep function is executed for the other 
circuits ([9] in FIG. 12). 

Thus, the statements of the system ABC are completed. In the 

15 embodiment, the bus connecting the modules are divided into the bus system, 
and the bus master interface, or the bus slave interface. Further, the objects 
(circuit modules) are described using the inheritance. Thus, the connection 
interface between the objects in the system can be described in integrated 
form. 

20 

[Header Files in Circuit Base Class] 

Next, the header files of the main circuit base classes will be 
explained with reference to FIGs. 14 to 23. In the figures, the comment lines 
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with "//" explain the details of the statements. In the statements, the 
functions with "virtual" and "=0", such as "virtual void Reset(void) = 01" (e.g., 
FIG. 14) are pure virtual functions, which means that the functions must be 
defined in the classes which inherit those classes. In the figures, the details 
5 of the statements of the functions are omitted, but only the comment lines 
remain for the better understanding. The contents of the figures will be 
explained in the followings. 

FIG. 14 shows the statements which define the CmComponent class. 
In the class CmComponent, the Reset function is defined as a pure virtual 

10 function. FIG. 15 shows the statements of the CmSyncModule class which is 
the derived class from the CmComponent class. In the CmComponent class, 
the OneStep function is defined as a pure virtual function. The 
CmSyncModule class is the derived class from the CmComponent class. 
Because the CmSyncModule class does not override the functions in the 

15 CmComponent class, the definitions of the functions in the CmComponent 
class are used as they are. 

FIG. 16 shows the statements of the CmBusMaster class which is the 
derived class from the CmSyncModule class. FIG. 17 shows the definition of 
the CmBusSlave class which the derived class from the CmSyncModule class. 

20 FIGs. 18 and 19 show the definitions of the CmBusMstlntf class which is the 
derived class of the CmSyncModule class. In the definition of the 
CmBusMstlntf class, the operation of the circuit by one step is described by 
the virtual function of "virtual void OneStep(void) {...}", shown in FIG. 19, 
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which overrides the OneStep function defined in the CmSyncModule class. 
The arguments of the AppendWriteData function, the Start Write function, 
the IsWriteEnd function, and the AppendReadAddress function, which are 
shown in FIG. 18, and the StartRead function, the IsReadEnd function, and 
5 the GetReadData function, which are shown in FIG. 19, are set to an integer 
variable mode, to thereby enable the operation of the transfer method (split 
transfer) which switches the master and the slave. FIGs. 20 and 21 show the 
definitions of the CmBusSlvIntf class which is the derived class from the 
CmSyncModule class. FIG. 22 shows the definition of the CmBusSystem 
10 class which is the derived class from the CmSyncModule class. FIG. 23 

shows the definition of the CmHier class which is the derived class from the 
CmSyncModule class. 



[Bus Simulation Method] 
15 Next, the bus simulation method, that is, the specific simulating 

operation will be schematically explained. The basic policy of the bus 
simulation is explained in the following. 

The bus master leaves the complicated control of the bus to the bus 
master interface. The bus master registers all the data, to be written or read, 
20 into the buffer in the bus master interface instantly. 

The communication from the bus master interface to the bus slave is 
executed whenever the OneStep function is executed. 

When the OneStep function is called, the bus master interface 
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extracts the data units one by one from the buffer, and sends it to the bus. 

The bus determines the target bus slave to be written or read, based 
on the bus read map, or on the bus write map, and sends a read or write 
command to the bus slave interface corresponding to the determined bus 
5 slave. 

The bus slave interface writes or reads data in the bus slave, 
depending on the instruction sent from the bus, and returns the result to the 
bus. 

The bus returns the result, sent from the bus slave interface, to the 
10 bus master interface. 

The bus master interface decides the operation in the next OneStep 
function, based on the result sent from the bus. 

Next, the flow of the execution of the functions in the embodiment 
will be explained by way of the example of writing data. In the system X 
15 shown in FIG. 24, a bus master Al, a bus master interface Bl, a bus CI, a 
bus slave interface Dl, and a bus slave El are connected in alphabetical 
order. The system is to write two pairs of units of information 
(address/data/bytes, 0x00100000/0x00112233/4, and 
0x00100004/0x44556677/4), which are shown in FIG. 25, from the bus 
20 master Al, e.g., a CPU, into the bus slave El, e.g., a memory. 

The statements of the system X, the bus master Al, the bus master 
interface Bl, the bus CI, the bus slave interface Dl, and the bus slave El 
inherits the properties of the classes described above. That is, the system X 
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inherits the CmSyncModule class, the bus master Al inherits the 
CmBusMaster class, the bus master interface Bl inherit the CmBusMstlntf 
class, the bus CI inherits the CmBusSystem class, the bus slave interface 
Dl inherit the CmBusSlvIntf class, and the bus slave El inherits the 
5 CmBusSlave class. These components are created by directly inheriting the 
classes, or by inheriting classes which inherit those classes. According to the 
UserWriteMap function in the system X, the addresses 0x00100000 and 
0x00100004 correspond to the bus slave interface Dl. When constructing the 
system X, the SetUserWriteMap function of the bus CI is executed, so that 

10 the UserWriteMap function of the system X is registered as the bus write 
map of the bus CI. The OneStep function for operating the bus master Al, 
the bus master interface Bl, the bus CI, the bus slave interface Dl, and the 
bus slave El by one step is always called from the OneStep of the system X. 

In the above construction, the operation of the system X in unit times 

15 1 to 4, shown in FIG. 26, will be explained with reference to FIGs. 27 to 30. 

[Time l] 

The operation of the system X in the time 1 will be explained with 
reference to FIG. 27. FIG. 27 shows the operations of the respective circuits 
20 in the manner of a time series within the same unit time (time l). In the 
time 1, the OneStep function of the bus master Al is executed. The bus 
master Al executes the function AppendWriteData (0, 0x00100000, 
0x00112233, 4) of the bus master interface Bl. Then, the bus master 
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interface Bl stores the data in the buffer. Then, the bus master Al executes 
the function AppendWriteData (0, 0x00100004, 0x44556677, 4) of the bus 
master interface Bl. The bus master interface Bl stores the data in the 
buffer. The bus master Al executes the StartWrite function of the bus master 
5 interface Bl. The bus master interface Bl memorizes the write request. The 
bus master Al executes the IsWriteEnd function of the bus master interface 
Bl. The bus master interface Bl returns the value, indicating that the bus 
Bl is writing the data, to the bus master Al. The bus master Al then goes on 
standby. 

10 When the One Step function of the bus master Al is completed, the 

OneStep function of the bus master interface Bl is executed. Since the bus 
master interface Bl has received the write request from the bus master Al, 
the bus master interface Bl requests the use of the bus. Accordingly, when 
the IsBusReq function of the bus master interface Bl is externally executed, 

15 the return value is true. Then, the OneStep function of the bus master 
interface Bl is completed. 

When the OneStep function of the bus master interface Bl is 
completed, the OneStep function of the bus CI is executed. The OneStep 
function of the bus CI operates the arbiter. The arbiter executes the 

20 IsBusReq function of the bus master interface Bl. The bus master interface 
Bl returns the request to use the bus. If the arbiter permits the bus master 
interface Bl to use the bus, the arbiter executes the AssertBusGnt function 
of the bus master interface Bl. The bus master interface Bl memorizes the 
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permission to user the bus. Then, the OneStep function of the bus CI is 
completed. 

When the OneStep function of the bus CI is completed, the OneStep 
function of the bus slave interface Dl is executed. In the time 1, the OneStep 
5 function of the bus slave interface Dl is completed without the execution of 
any process. 

When the OneStep function of the bus slave interface Dl is 
completed, the OneStep function of the bus slave El is executed. The special 
operation of the bus slave El is performed, but does not includes the 
10 operation in connection with the bus. 



[Time 2] 

Next, the operation of the system X in the time 2, which is the next 
unit time, will be explained with reference to FIG. 28. In the time 2, the 

15 OneStep function of the bus master Al is executed in a manner similar to 
that in the time 1. The bus master A 1 executes the IsWriteEnd function of 
the bus master interface Bl. The bus master interface Bl returns the value 
indicating that the bus master interface Bl is writing the data. Then, the 
bus master Al then goes on standby. 

20 When the OneStep function of the bus master Al is completed, the 

OneStep function of the bus master interface Bl is executed. Since the 
OneStep function of the bus master interface Bl permits the bus master 
interface Bl to use the bus, the bus master interface Bl writes the data into 
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the bus. That is, the following operation is performed. The bus master 
interface Bl extracts one data unit from the buffer. At that time, the address 
is OxOOlOOOOO, the data is 0x00112233, and the number of bytes is 4. Then, 
the bus master interface Bl executes the function WriteMap (0x00100000, 
5 0x00112233, 4) of the bus CI. 

Then, the WriteMap function of the bus CI performs the following 
operations. The function AppendWriteData (0, 0x00100000, 0x00112233, 4) 
of the bus slave interface Dl is executed. The bus slave interface Dl stores 
the given data into the buffer. The Start Write function of the bus slave 

10 interface Dl is executed. The bus slave interface Dl executes the function 
WriteBusSlave (0x00100000, 0x00112233, 4) of the bus slave El. The bus 
slave El stores the given data into the buffer. The bus slave El returns the 
value indicating whether the writing has been successful, to the bus slave 
interface Dl. In the example, the writing has been successful. The 

15 IsWriteEnd function of the bus slave interface Dl is executed. Because the 
writing of the data into the bus slave El by the bus slave interface Dl has 
been successful, the return value is true. Thus, the return value of the 
IsWriteEnd function of the bus slave interface Dl is returned. 

The bus master interface Bl comes to know, based on the return 

20 value, that the data has been successfully written. Then, one unit of the data 
is deleted from the buffer. Since one data unit remains in the buffer of the 
bus master interface Bl, the same operation is performed in the next 
OneStep of the bus master interface Bl. 
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When the One Step function of the bus master interface Bl is 
completed, the OneStep function of the bus CI is executed. In the time 2, the 
OneStep function of the bus CI executes nothing. 

When the OneStep function of the bus CI is completed, the OneStep 
5 function of the bus slave interface Dl is executed. In time 2, the OneStep 
function of the bus slave interface Dl executes nothing. 

When the OneStep function of the bus slave interface Dl is 
completed, the OneStep function of the bus slave El is executed. The special 
operation of the bus slave El is performed, but does not includes the 
10 operation in connection with the bus. 



[Time 3] 

In the time 3, as shown in FIG. 29, the OneStep function of the bus 
master Al is executed. The OneStep function of the bus master Al executes 

15 the IsWriteEnd function of the bus master interface Bl. The bus master 

interface Bl returns the value indicating that the bus master interface Bl is 
writing the data. The bus master Al then goes on standby, and the OneStep 
function of the bus master Al is completed. 

When the OneStep function of the bus master Al is completed, the 

20 OneStep function of the bus master interface Bl is executed. Since in the 
time 3 the OneStep function of the bus master interface Bl permits the bus 
master interface Bl to use the bus, the bus master interface Bl writes the 
data into the bus. That is, the following operation is performed. 
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The bus master interface Bl extracts one data unit from the buffer. 
At that time, the information includes the address of 0x00100004, the data 
of 0x44556677, and the number of bytes of 4. Then, the bus master interface 
Bl executes the function WriteMap (0x00100004, 0x44556677, 4) of the bus 
CI. 

Then, the WriteMap function of the bus CI performs the following 
operations. The WriteMap function of the bus CI executes the function 
AppendWriteData (0, 0x00100004, 0x44556677, 4) of the bus slave interface 
Dl. The bus slave interface Dl stores the given data into the buffer. The 
WriteMap function of the bus CI executes the Start Write function of the bus 
slave interface Dl. The bus slave interface Dl executes the function 
WriteBusSlave (0x00100004, 0x44556677, 4) of the bus slave El. The bus 
slave El stores the given data into the buffer. The bus slave El returns the 
value indicating whether the writing has been successful. In the example, 
the writing has been successful. The WriteMap function of the bus CI 
executes the IsWriteEnd function of the bus slave interface Dl. Because the 
writing of the data into the bus slave El by the bus slave interface Dl has 
been successful, the return value is true. Thus, the WriteMap function of the 
bus CI returns the return value of the IsWriteEnd function of the bus slave 
interface Dl. 

The bus master interface Bl comes to know, based on the return 
value, that the data has been successfully written. Then, one of the data is 
deleted from the buffer. Because no data remains in the buffer of the bus 
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master interface Bl, the bus master interface Bl completes the writing 
operation. Therefore, the return value of the IsWriteEnd function of the bus 
master interface Bl becomes true. Then, the OneStep function of the bus 
master interface Bl is completed. 

When the OneStep function of the bus master interface Bl is 
completed, the OneStep function of the bus CI is executed. The OneStep 
function of the bus Cl executes nothing, and is completed. 

When the OneStep function of the bus Cl is completed, the OneStep 
function of the bus slave interface Dl is executed. The OneStep function of 
the bus slave interface Dl executes nothing, and is completed. 

The OneStep function of the bus slave El is executed. The special 
operation of the bus slave El is performed, but does not includes the 
operation in connection with the bus. 

[Timer 4] 

In the time 4, as shown in FIG. 30, the OneStep function of the bus 
master Al is executed. In the OneStep function of the bus master Al in the 
time 4, the bus master Al executes the IsWriteEnd function of the bus 
master interface Bl. The bus master interface Bl returns the value 
indicating that the writing has been finished. Then, the bus master Al starts 
the following operations. The OneStep function of the bus master interface 
Bl, the OneStep function of the bus Cl, and the OneStep function of the bus 
slave interface Dl are executed in order in the time 4. The OneStep 
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functions do not execute any process. Then, the OneStep function of the bus 
slave El is executed. The special operation of the bus slave El is performed, 
but does not includes the operation in connection with the bus. 

Thus, according to the operations in the times 1 to 4, the writing 
operation of the data, shown in FIG. 25, is completed. 

[Split Transfer] 

The other embodiment of the data transfer through the bus will be 
explained. The bus normally sends an instruction to write or read data only 
in the direction from the bus master to the bus slave. When a high 
performance bus cannot immediately respond to the read/write request sent 
from the bus master to the bus slave, the bus disconnects the communication, 
and then actively returns a value in the reverse direction from the bus slave 
to the bus master. This method is termed split transfer. The split transfer 
means a series of operations in which the master transmits an instruction to 
the slave, and after the transmission is completed, the slave transmits an 
instruction to the master in turn. The split transfer is achieved by a high 
performance bus. The simulation of the split transfer according to the 
embodiment will be explained. 

In the split transfer, the relationship between the slave and the 
master is inverted. 

That is, the bus slave leaves the complicated control of the bus to the 
bus slave interface. The bus slave registers all the data, to be written or read, 
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into the buffer in the bus slave interface in a moment. 

The communication from the bus slave interface to the bus master is 
executed whenever the OneStep function is executed. 

When the OneStep function is called, the bus master interface 
5 extracts the data units one by one from the buffer, and sends it to the bus. 

The bus determines the target bus master to be written or read, 
based on the bus read map, or on the bus write map, and sends a read or 
write command to the bus master interface corresponding to the determined 
bus master. 

10 The bus master interface writes or reads data in the bus master, 

depending on the instruction sent from the bus, and returns the result to the 
bus. 

The bus returns the result, sent from the bus master interface, to the 
bus slave interface. 

15 The bus slave interface decides the operation in the next OneStep, 

based on the result sent from the bus. 

To achieve the above functions, the bus slave and the bus master 
have the same functions, and the bus slave interface and the bus master 
interface have the same functions. Accordingly, in the embodiment, the bus 

20 slave and the bus master have the same configuration, and the bus slave 
interface and the bus master interface have the same configuration. To 
determine the direction of the transmission (that is, the master to the slave, 
or the slave to the master), the functions such as the AppendWriteData 



49 

function have arguments "mode" (see FIGs. 18, 19, 20, and 21). When mode 
is 1, the reverse operation is performed. 



[Examples of Created Circuit Class] 
5 Next, an example of creating a new circuit class will be explained. A 

user is to create a new bus master interface class with the name of 
CUserBusMstlntf. It is first declared that the new class CUserBusMstlntf 
inherits the CmBusMstlntf class. Accordingly, the CUserBusMstlntf class 
has the same functions as those of the CmBusMstlntf class. Then, these 

10 functions are overridden to create the new class CUserBusMstlntf which 
achieves the desired operations. 

Another example of creating a new circuit class is shown, The user is 
to create a new CPU class with the name of CUserCpu. It is first declared 
that the new class CUserCpu inherits the CmCpu class. Accordingly, the 

15 CUserCpu class has the same functions as those of the CmCpu class. Then, 
these functions are overridden to create the new class CUserCpu which 
achieves desired operations. 

[Main Advantages of the Embodiments] 
20 The first advantage is that it is easy to replace the circuit module. 

That is, when one of the circuit modules in the system is replaced, the 
statements of the other circuit modules need not be changed. 

The second advantage is that the connections between the circuit 



modules are automatically checked. That is, if the circuit modules are 
incorrectly connected, the compiler causes an error when in the compiling 
process. 

The third advantage is that the configuration for displaying the 
5 information is commonly used by the circuit modules having the same 

property. That is, the configuration for displaying the information need not 
be separately prepared for each circuit module. 

The fourth advantage is that the configuration for controlling the 
simulation is commonly used by the systems which are the simulation 
10 targets. That is, even if the system of the simulation target is changed, the 
configuration for controlling the simulation need not be changed. 

The fifth advantage is that it is automatically checked whether the 
statements of the circuit interfaces are sufficient. That is, if the statements 
are insufficient, the compiler causes an error when in the compiling process. 

15 

[Reasons for the Above Advantages] 
The reason for the first advantage- 

The reason for the first advantage will be explained with reference to 
FIGs. 31 to 33. FIG. 31A shows the examples of the statements of a class 
20 ClassX, and FIG. 3 IB shows the relationship between the ClassX class and 
the CmBusMstlntf class. As shown in FIG. 31A, in the class ClassX, a 
function ConnectBusMstlntf for connecting the circuit base class 
CmBusMstlntf to the class ClassX is defined ([l] in FIG. 31A), and the 
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AppendReadData function and the StartRead function of the object 
BusMstlntf of the circuit base class CmBusMstlntf is executed ([2] and [3] in 
FIG. 31A). Thus, as shown in FIG. 31B, the object of the class ClassX can 
execute the AppendReadData function and the StartRead function of the 
5 object of the class which inherits the circuit base class CmBusMstlntf. 

In the statements, shown in FIG. 32A, of the system having the 
object ObjectX of the class ClassX, and the object PciBusMstlntf of the class 
CmPciBusMstlntf which is the derived class from the circuit base class 
CmBusMstlntf, the ObjectX is defined as the object of the ClassX ([l] in FIG. 

10 32A), the object PciBusMstlntf is defined as the object of the class 

CmPciBusMstlntf ([2] in FIG. 32A), and the ObjectX is connected to the 
object PciBusMstlntf by the ConnectBusMstlntf function. As shown in FIG. 
32B, the ObjectX can execute the AppendReadData function and the 
StartRead function of the object PciBusMstlntf. 

15 In FIGs. 33A and 33B, the bus master interface object connected to 

the ObjectX is changed from the object PciBusMstlntf to the object 
UserBusMstlntf of the class CUserBusMstlntf which is derived from the 
common circuit base class CmBusMstlntf. To achieve the change, the object 
UserBusMstlntf is declared as the class CUserBusMstlntf, and the 

20 argument for executing the ConnectBusMstlntf of the ObjectX is simply 
changed from the address of the object PciBusMstlntf to the address of the 
object UserBusMstlntf. In this case, the statement of the object ClassX need 
not be changed. 
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As described above, when the circuit base class is common, for 
example, when the circuit base class CmBusMstlntf is defined as the base 
class for all the bus master interfaces, one of the classes ClassX declares that 
the bus master interface to communicate with is the CmBusMstlntf class. 
Even when the bus master interface to communicate with is changed, the 
statements of the ClassX need not be changed, and the object of the ClassX 
can communicate with the changed bus master interface according to the 
procedure defined in the CmBusMstlntf class. That is, even when connecting 
the circuit module X to a new bus master interface class CUserBusIntf, the 
statements of the circuit module X need not be changed. 

When no circuit base class exists, to send an instruction from a 
circuit class X to the CUserBusMstlntf, it must be described in the 
statements of the class X that the receiver of the instruction of the class X is 
the object of the class CUserBusMstlntf. Therefore, to change the connection 
of the class X from the bus master interface to the CUserBusMstlntf, the 
statements of the class X must be changed. 

Another example will be explained with reference to FIGs. 34 to 36. 
There is a circuit class ClassY. The ClassY reads a value from a terminal of 
another circuit, and is operated based on the value. According to the concept 
of the circuit base class, the statements (FIG. 34A) of the ClassY describe 
that the circuit object to be read is the CmComponent class ([l] in FIG. 34A). 
The GetPinValue function of the CmComponent class is executed to read the 
value at the terminal ([2] in FIG. 34A). It should be noticed that there is 
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inheritance between the circuit base classes. For example, when The 
CuserCpu ([4] in FIG. 35), shown in FIGs. 35Aand 35B, inherits the CmCpu 
class, the CUserCpu also inherits the CmComponent class. Accordingly, the 
CUserCpu has the properties of the CmComponent class. When using the 
5 member functions defined in the CmComponent class, the CUserCpu object 
can be connected to the object ClassY even if the statements of the class 
ClassY are not changed. 

As described above, when there is inheritance between the circuit 
base classes, as the circuit module can be replaced, and the statements need 
10 not be changed. 



The reason for the second advantage: 

In FIGs. 36A and 36B, the class CUserBusMstlntf derived from the 
circuit base class CmBusMstlntf of the bus master interface is to be 

15 incorrectly connected to the object BusSlave of the bus slave class 

CmBusSlave by the ConnectBusSlvIntf function. The ConnectBusSlvIntf 
function can connect the class CUserBusMstlntf only to the class whose base 
class is the CmBusSlvIntf class. When compiling the codes which connect the 
class whose base class is not the CmBusSlvIntf class, the C++ compiler 

20 outputs an error when checking the types of the classes in the compiling 
process according to the C++ specification. Therefore, it is automatically 
detected that the class CUserBusMstlntf which does not inherit the circuit 
base class CmBusSlvIntf is to be incorrectly connected to the class 
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CmBusSlave ([1] in FIG. 36A). Thus, because the incorrect connection 
always causes an error, this helps the user to correctly connect the classes. 



The reason for the third advantage 
5 The information display section of the object Cpu for the model of the 

CPU processes the information obtained by the functions, such as the GetPc 
function, and the GetReg function, for extracting the internal state of the 
object Cpu, and displays the internal information to the user. The 
information display section is defined in the circuit base class CmCpu, and it 

10 is described that the object Cpu is in the CmCpu class. Accordingly, the 
circuit Cpu which inherits the CmCpu class can use the information 
processing section. For example, when the new user created class CUserCpu 
inherits the CmCpu class, the CUserCpu class can use the information 
processing section of the CPU defined in the class CmCpu. That is, a new 

15 information display section for a new CPU class CUserCpu need not be 
prepared. 

The reason for the fourth advantage 

Since the system is a sequential circuit (clock synchronous circuit) 
20 having a clock, the system has the property of the CmSyncModule class. The 
simulation controller handles the system as the CmSyncModule class, and 
controls the simulation by the Reset function, the OneStep function, etc. 
Thus, as long as the systems inherit the CmSyncModule class, the single 
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configuration for controlling the simulation can be commonly used by all the 
systems. 

The reason for the fifth advantage 
5 In the bus slave, the ReadBusSlave function, and the WriteBusSlave 

function send, or receive the value to or from the bus. The contents of the 
processes must be described. In the circuit base class CmBusSlave class of 
the bus slave, the ReadBusSlave function, and the WriteBusSlave function 
are pure virtual functions. Therefore, even when there is an omission in the 

10 statements of the ReadBusSlave function, and the WriteBusSlave function in 
the bus slave circuit class, the C++ compiler outputs an error message, 
indicating that the pure virtual function is not overridden in the compiling 
process as long as the CmBusSlave class is inherited Thus, the omission in 
the statements of the necessary functions can be automatically checked. 

15 The above -de scribed embodiments are to be considered illustrative, 

and the present invention is not limited to the embodiments. For example, 
the object oriented language is not limited to the C++ language, and may be 
a language, such as JAVA, which is equal to the configuration for providing 
the object oriented technique such as inheritance, classes, etc. The circuit 

20 base classes are not limited to the above classes! a new class with the 
property of an optional circuit module may be added, and a class which 
integrates the above classes may be created. 

The simulation method and apparatus of the present invention can 
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be provided by a computer and a simulation program executed by the 
computer. The program, to be executed by the computer, can be distributed 
by a computer-readable storage medium. 

The present invention describes the system with a plurality of 
modules using the features of the object oriented language such as the 
inheritance, and the classes. Therefore, when simulating the system, the 
statements of the circuit modules and the connections between the modules, 
and the expansion or change of the circuit modules and the system can be 
easily and reliably achieved as compared with the conventional technique. 

This invention may be embodied in other forms or carried out in 
other ways without departing from the spirit thereof. The present 
embodiments are therefore to be considered in all respects illustrative and 
not limiting, the scope of the invention being indicated by the appended 
claims, and all modifications falling within the meaning and range of 
equivalency are intended to be embraced therein. 



